1. Field of the Invention
This invention relates to data processing systems, methods, and computer program products, and more particularly to configuration files for data processing systems, methods, and computer program products.
2. Description of the Related Art
A given data processing system may be configured in many ways. Some of the configuration options are set by varying the hardware (e.g., number and capacity of disk drives). Other configuration parameters are set within configuration files stored by the computer.
Software programs typically use configuration files of one kind or another to define customizable properties. One very common configuration file format, used by “INI” files on the Windows operating system, divides configuration properties into sections, as follows:
property1=value1
[section2]
property1=value1
property2=value2
Configuration files are typically used because they can be edited using a simple text editor, thereby enabling end-users to easily make changes to them. Therefore, their use has become pervasive in application development. Some examples of properties that are often stored in configuration files include user-interface related information, such as colors, font types, font sizes, etc.; prerequisite software locations, versions, and related information; and debug settings.
Typical configuration files are static in nature (i.e. properties are only simple textual strings that contain no variables). This static nature of configuration files renders their use sub-optimal in some circumstances. When defining locale-specific values, multiple configuration files need to be created when a particular property needs to vary from one locale to the next. For example, situations arise when it is desired to define different font-types or font-sizes depending on the locale (e.g., a Japanese-language font versus an English-language font). Using typical configuration files in multi-language development, this could be accomplished by creating separate configuration files for each locale, or having the end-user manually update these fields to match the settings for the desired locale. Either process (separate configuration files or manual updating) are tedious and time-consuming.
Another situation where the static nature of configuration files is not adequate occurs when a property in one configuration file needs to reference a second property in the same or different configuration file. For example, many applications define properties for directories used by an application (e.g. where to put log files, where to find libraries, etc.). Often these directories are located inside the ‘install’ directory by default, but are exposed to the end-user so that these directories can be modified at a later date. Using typical configuration files, each of these dependent properties have to be defined separately, as follows:
[Paths]
installDir=C:\Program Files\My Product
logDir=C:\Program Files\My Product\logs
libDir=C:\Program Files\My Product\lib
Unfortunately, if the install location changes (e.g., if the install directory changes from “My Product” to “Their Product”), each property containing the install location (e.g., “logs” and “lib” in the above example) must also be updated. This can be particularly tedious if these dependent properties are scattered throughout the configuration file, or even defined in different configuration files.
Accordingly, it would be desirable to have the ability to include dynamic elements in configuration files and then resolve the variables when the configuration files are run.